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^ (57) Abstract: A method of processing reservation deposits provides for classifying prospective visitors to an event (11, 13, and 
O 15) ^ d 016 acc0mmodations available for reservation to the visitors. Attendee attrition is minimized by assigning dates* prior to 
the start of the event for processing of credit card authorizations, collection of deposits, and full or partial refunds for cancellations. 
W An increasing scale of penalties is applied between the processing fee date and a cancellation close date after which deposits are 
^ entirely forfeited upon cancellation. Business rules may be applied to the reservation, collection and cancellation payment process 
^ as a function of the classes of attendees and the accommodations. 
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METHOD OF PROCESSING RESERVATION DEPOSITS 
■ Background of the Invention 

This invention provides a method of processing guest 
hotel room reservation deposits, and making refunds for 
cancelled hotel reservations for conventions and similar 
events. More specifically, the invention provides a 
method by which a single entity can service multiple 
prospective guests making reservations among multiple 
hotels in connection with a convention or similar event, 
and can provide reservation status information to the 
guests and hotels, the convention sponsor, meeting 
planners, housing managers, and other personnel having a 
need for such information. 

It is known in the art to provide a central 
information system for convention hotel reservations to 
the various parties concerned with planning for, and 
attendance at/ a convention. However, the processing of 
reservations, reservation deposits, and reservation 
deposit refunds has, heretofore, required direct 
communication between attendees and the respective hotels 
in which rooms are being made available, or their agents. 
Reservation processing, is further complicated by the need 
to enforce different sets of hotel attendance rules 
applicable to each respective convention, concerning 
matters such as level of accommodations, hotel locations 
relative to meeting centers, and proximity of different 
classes of attendees to one another. 

In addition to the large number of personnel and 
substantial effort that must be dedicated to the 
processing of convention hotel reservations, prior art 
systems further suffer insofar as they encourage multiple 
booking of hotel rooms by convention attendees, and the 
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resulting attendee attrition which follows as unneeded 
reservations are cancelled. 

Summary of the Invention 

The present invention overcomes the above described 
5 shortcomings of the prior art in providing a method of 
processing reservation deposits including storing, in a 
computer memory, data describing a plurality of rooms, tbe 
data comprising a quality classification for each room 
indicative of a class of visitors to whom reservations of 

10 said room are to be limited, and an inventory code for 
each of a plurality of dates indicative of whether or not 
the room is available for occupancy on each of the dates. 
For each visitor, there is stored in the computer memory, 
data describing a reservation request made by the visitor, 

15 the data describing the reservation request including a 
visitor class code assigned to -the visitor, data 
indicating the stay dates for which at least one room is 
sought to be reserved by the visitor, and data identifying 
a financial institution and account therein from which 

2 0 collection of a deposit to secure the visitor's 

reservation may be made. 

The visitor class code is compared with the quality 
classification for each room having an inventory code 
indicating that the room is available for each of the 
25 dates for which the reservation is sought. In response to 
the comparison signaling the availability on each of the 
stay dates, of a room having a classification 
corresponding to the visitor class code, the inventory 
code for the room is changed to indicate that it is no 

3 0 longer available, the room being reserved to the visitor 

For each visitor whose reservation has not been 
cancelled by the processing fee date, a collection request 
is generated for collecting the visitor's deposit payment 
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from the financial institution. For each visitor whose 
reservation has not been cancelled by a reservation 
closing date, a transfer of funds to the hotel is 
initiated on a funds transfer date, the funds being equal 
5 in amount to a portion of the deposit from which there is 
excluded a processing fee. 

A database with records of reservation requests and 
respective deposit payment offers is maintained. A 
comparison is made of the present time and a predetermined 

10 time for processing the reservation deposits and, if the 
present time is equal to or greater than the predetermined 
processing time, for each record of a reservation 
requested by a visitor, a collection request for 
transferring funds from a financial institution in which 

15 an account has been opened for the benefit of the visitor 
for payment of the deposit is initiated. 

For each record of a request for cancellation of a 
reservation by a visitor, the time of the request is 
compared with the processing time, and from the comparison 

20 a determination is made as to whether a refund is due in 
response to the cancellation. A processing fee which is a 
function of the elapsed time between the processing time 
and the cancellation request time is subtracted from the 
_ deposit . 

25 The present time is also compared with a 

predetermined funds transfer date later than the close 
time, and if the present time is later than the close 
time, a fund transfer request for transferring funds to a 
financial institution in which an account has been opened 

3 0 for the benefit of the beneficiary merchant is initiated. 
Description of the Drawings 

Fig. l is a schematic diagram showing the 
communication paths between attendees of an event and a 
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commerce processor for performing the method of the 
preferred embodiment of the invention. 

Fig, 2 is a flow diagram depicting steps of the 
method of the preferred embodiment of the invention. 
5 Fig. 3 is a graph of events versus time for the 

processing of deposits in accordance with the method of 
the preferred embodiment of the invention. 

Fig. 4 is a graph of events versus time for the 
processing of cancellation xefund requests in accordance 
10 with the method of the preferred embodiment of the 
invention. 

Fig. 5 is a chart showing the relationship among 
modules of a computer program for performing the method of 
the preferred embodiment of the invention. 
15 Fig- 6 is a schematic block diagram of a module of 

the computer program illustrated to in Fig. -5. 

Fig. 7 is a schematic block diagram of another module 
of the computer program illustrated to in Fig. 5. 

Fig. 8 is a schematic block diagram of still another 
20 module of the computer program illustrated to in Fig. 5. 

Fig. 9 is a schematic block diagram of a further 
module of the computer program illustrated to in Fig. 5. 

Fig. 10 is a schematic block diagram of a still a 
further module of the computer program illustrated to in 
25 Fig. 5. 

Description of the Preferred Embodiment 

Referring now to Fig. 1 of the drawings, individual 
attendees or their agents can make hotel reservations by 
communicating with a central reservation and deposit 
3 0 management facility operated under the control of a 
software-based reservation management system, sometimes 
hereinafter referred to as a commerce processor. The 
commerce processor is capable of processing reservation 
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deposits, which includes both payments and refunds. The 
computer program automates the process of authorizing 
credit cards used as a deposit in reserving a hotel room 
as well as initiating the transfer of funds from the 
payment processor to the specified merchant. The program 
also reports all failed transactions, which may. then be 
investigated and resolved. 

Communication with the reservation facility can take 
any form including telephone, fax, email or even personal 
visit to the central reservation facility. However, the 
most advantageous form of communication will be by 
accessing the central reservation facility's web site on 
the Internet. 

Attendees may be of different classes, each of which 
will receive correspondingly different treatment in 
accordance with business rules usually promulgated by the 
convention sponsor. For example attendees may be 
respectively classified as general conference attendees 
11, very important (VIP) conference attendees 13, and 
conference speaker attendees 15. 

Requests for reservations received in the central 
reservation and deposit management facility, orally or in 
writing, are converted into machine readable form. 
Referring additionally to Fig. 2, requests 'for 
reservations received in the central reservation and 
deposit management facility are made by the visitor or 
attendee, or an agent, completing a form on a web page 
that is accessible on the Internet, thereby ensuring 
compatibility with the central reservation and deposit 
management facility software. These forms are provided 
with the necessary menus and controls, e.g.,. check boxes, 
dropdown lists, combo boxes and the like as will be known 
to those skilled in the art. Rules for data entry, such as 



WO 00/72214 PCT/US00/14425 

-6-- 

field sizes, capitalization, punctuation are enforced at 
the form level and necessary conversions of obvious errors 
can be made to ensure consistency with the input data 
requirements of the commmerce processor software. 
5 Reservation requests from the various classes of 

attendees, in machine readable form, are stored in a 
reservation database .accessible by a computer on which the 
commerce processor program resides- Associated with each 
reservation is a deposit fee payable to the operator of 

10 the commerce processor as a service charge for entering 
each reservation received into the reservation database 
and a processing fee for collecting the funds in payment 
of the deposit . 

Each reservation in the master reservation system is 

15 entered into a commerce transaction process table for 
processing on dates which will normally be predetermined 
for each event that is being attended. Referring to Figs. 
3 and 4, reservations 'are accepted over a continuous range 
of dates beginning with a reservation open date and ending 

20 with a close date after which reservations are no longer 
accepted and deposit refunds are no longer made. 

In the preferred embodiment of the invent ion , the 
commerce processor program credits its operator with two 
payments for each reservation. The first payment is 

25 earned, on all reservations, on a predetermined date 
subsequent to the reservation open date.. The second 
payment is a processing service charge which is earned 
when the deposit payment is processed for collection on a 
predetermined date subsequent to the deposit fee date. No 

3 0 processing fee payment is earned on reservations cancelled 
before the processing fee date. 

Referring to Fig. 2, the commerce processor software 
cyclically . compares the current date with the 
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predetermined deposit fee date, processing fee date, close 
date,, and a funds transfer date for each reservation and 
performs the actions scheduled for those dates. 

Each record of a reservation requested in connection 
5 with the event is selected from the commerce transaction 
process table. If payment of the reservation deposit by 
credit card has been requested, an authorization request 
is constructed and transmitted to a clearing house for 
such requests. A record of the authorization request is 

10 entered into a commerce transaction history table. 

A corresponding authorization response request is 
then received from the clearing house. The commerce 
processor software tests the response and, if a credit 
card charge authorization has been granted, an order to 

15 charge the deposit to the credit card account is 
constructed and retransmitted to the clearing house. 

The clearing house transmits an acknowledgement of 
the credit card charge order to the reservation facility 
which is reported to the commerce processor software. In 

20 response to a successful acknowledgment, the commerce 
processor software then causes a confirmation of the 
reservation to be transmitted to the attendee by email. 
The commerce processor software then tests for whether 
there are more reservations to be processed and, if there 

25 are, repeats the foregoing procedure. If there are no more 
reservations, processing is halted until another 
reservation is received. 

If a successful acknowledgement of the credit card 
deposit charge order is not received, a record of the 

30 failure is written to a table of failed acknowledgement 
requests for later follow-up and is also recorded in the 
log of failed commerce transactions. Reservations may be 
received before and after the processing fee date. 
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Reservations received before the processing fee date are 
batch processed on the processing fee date. Reservations 
received after the processing fee date are generally 
individually processed substantially immediately after 
5 receipt . 

If a credit card charge authorization has been denied 
in response to an authorization request sent to the 
clearing house, a record of the failed transaction is 
entered into a daily log by the commerce processor 

10 software. Manual follow-up of failed authorization 
requests and charge acknowledgements can be done at a 
terminal from which the commerce transaction history table 
and failed commerce transaction log can be accessed. 

Referring again to Fig. 1, the commerce processor 

15 software includes a group inventory manager module 17. The 
group inventory manager module 17 is connected to a 
database containing hotel inventory records 19 each of 
which can be associated with a hotel room. The rooms can 
be categorized into blocks, each block being preassigned 

20 to different type or class of attendees. That is one block 
may be assigned for occupancy by general attendees 11, 
another block- for VIPs 13 and a third block for speakers 
15. 

Inventory is broadly categorized as "available" or 
25 "booked." As each room reservation is accepted, one or 
more fields of each relevant record in the inventory 
database is updated to reflect the assignment of a room to 
the reservation. Assigned rooms are classified as "booked" 
and removed from the blocks of rooms available for 
30 assignment to fill future reservations. 

Thus, the group inventory manager module 17, receives 
requests for inventory from multiple classes of possible 
attendees, filters available inventory and offers only 
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inventory that complies with business rule constraints in 
the database, allocates inventory based on business rules 
for attendee class, length of stay and number of guests, 
imposes and discloses constraints on cancellation, updates 
the information in an inventory configurator module 21, 
and receives messages from a payment controller module 23. 

Referring additionally to Pigs. 5 and .6, an inventory 
configurator module 21 of the commerce processor program 
code is provided with data specifying the number and 
quality of rooms available at each hotel property 
participating in the convention. Data may also be provided 
ranking each hotel property in accordance with 
desirability, taking into account such factors as distance 
to convention events, condition of physical plant, and 
amenities offered to guests. 

In accordance with business rules set forth in the 
code contained in the inventory configurator module 21, 
the inventory configurator module 21 allocates a different 
attendee code to each class of attendee. Depending on the 
size of the convention, the inventory configurator module 
21 may assign individual rooms or blocks of rooms for 
occupancy by different classes of attendees. A minimum 
number of nights for which each room or block of rooms may 
be reserved is designated by the inventory configurator 
module 21 as a function, of the class of attendee, i.e., 
attendee code, for which the room or block of -rooms has 
been allocated. The number of guests who are to occupy 
each room is also designated by the inventory configurator 
module 21 as a function of attendee code corresponding to 
the room, or the block of rooms or which it is a member. 

In accordance with agreements between the convention 
sponsors and participating . hotel merchants, different 
rooms or blocks of rooms may be removed from the 



WO 00/72214 



PCT/USOO/14425 



participating hotels 1 regular inventories of rooms 
available to the general public, for different ranges of 
dates. For example, it may be desired to have .VIPs 13 
arrive earlier than other attendees to participate in 
5 special functions. Or, speakers 15 who are only giving 
presentations over one or two days of a longer convention 
may require rooms for a briefer range of dates than other 
attendees. In order to accommodate differences in stay 
dates, the inventory configurator module 21 receives 

10 business rules and applies the rules to each block of 
rooms as a function of the codes of the attendees 
respectively/ assigned to the block of rooms. 

Room rates can also be assigned by the inventory 
configurator module 21 to each block of rooms according to 

15 the class of attendees to whom the rooms are assigned. For 
example, the rooms occupied by speakers 15 may be paid for 
by the convention sponsor and allowed a discount in 
accordance with the convention sponsor's contract with the 
hotel (s) . 

20 The group inventory control manager module 17 

arbitrates requests for reservations from, and assignment 
of rooms to, attendees. The group inventory manager module 
17 receives reservation requests from multiple classes of 
attendees, and their agents, upon their transmission to 
-25 the central reservation facility. 

Upon receipt of a reservation request, the group 
inventory manager module 17 interrogates the room 
inventory database in accordance rules stored in the 
inventory configurator module 21. That is, the room 

30 inventory is filtered in accordance with the class of 
attendee for whom a reservation is requested and the pool 
of unassigned rooms. Other factors used in filtering the 
room inventory may include the type and length of stay for 
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which a reservation is being sought, that is the number of 
nights and beginning date of the stay, and the number of 
guests who, with the attendee, are to occupy the reserved 
room(s). Thus the requester is offered a room only from 
those blocks of rooms which have been allocated to 
attendees of the requester's class, that is those rooms 
associated with the . attendee code of the reservation 
requester, the requested time and type of stay, and the 
number of guests sharing the roorn(s) . Cancellation terms 
and penalties applicable to the class of attendee are also 
disclosed to the reservation requester at the time that 
the reservation is booked. The group inventory manager 
module 17 communicates directly with the inventory 
configurator module 21 to apply the business rules 
governing the reservation of rooms to the attendees for 
whom reservations are sought. 

In addition to having code for performing room 
inventory management and allocation functions, the 
commerce processor software includes code for processing 
reservation deposits. The payment controller module 23 
(see Fig. io) includes payment configurator code in which 
there are stored business rules governing the handling of 
reservation deposits, authorizations and refunds. The 
payment controller has payment configurator code which 
determines the processing fee dates for each of the types 
of transactions, i.e., credit card authorizations, 
collection of deposits by initiating charges to credit 
cards or depositing checks for collection, and issuing of 
credits to credit cards for refundable cancellations. The 
payment controller has credit card controller code for 
transmitting charge and credit transaction requests to an 
electronic payments system,, and check controller code for 



WO 00/72214 



-12- 



PCT/US00/I4425 



transmitting requests for collection of deposits made by 
check to a banking system. 

The payment controller module 23 can have stored 
within it, for each class of attendee, a plurality of 
dates in the cycle of the processing of a payment listed 
in chronological order as follows: 

1. Reservation Open Date - The date when 
reservations can first be made for an attendee of a given 
class. 

2. Deposit fee date - The date by which the 
attendees deposit must be received in order to avoid 
cancellation of the reservation. 

3. Processing fee date - The date by which a 
predetermined portion of the attendee's deposit is earned 
by and paid to the operator of the commmerce processor, 
and is nonrefundable to the attendee. In the preferred 
embodiment of the invention, the processing fee is a fixed 
fee per transaction collected once for each attendee 
reservation. If desired, the processing fee can be 
computed as a percentage of the value of the attendee ' s 
stay to the participating hotel. 

4. Cancellation Close Date - The date by which the 
entire reservation deposit becomes nonrefundable to the 
attendee. 

5. Funds Transfer date - The date on which the 
operator of the central reservation and deposit management 
facility transfers to the room provider hotel merchants, 
the reservation deposits, less refunds made prior to the 
cancellation close, date and processing fees earned by the 
central reservation and deposit management facility 
operator. 

6. Event date - The date on which the convention or 
other sponsored event begins . 
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For each date in the event cycle, the payment 
controller code determines, for each attendee on behalf of 
whom a reservation requests has been made, which processes 
are to be performed, including credit card authorization, 
5 charging of deposit to credit card account, deposit of 
reservation check for collection by financial institution, 
and refund of deposit by issuance of check or credit to 
attendee's credit card account. 

The payment controller code presorts the various 

10 processes by type and then transmits the data for batch 
processing. For example, all credit card authorization 
requests may be transmitted via credit card controller 
code to an external electronic payments system for 
approval. Similarly, authorized credit card deposits may 

15 be communicated to the electronic payments system in a 
batch process by the credit card controller code. Check 
payments are routed, in bulk, to the banking system* for 
collection via check controller code. 

As status messages are received from financial 

20 institutions and other parties to the payment settlement 
process they are distributed for access by those having a 
need to know. Result messages indicative of the timeliness 
and validity of deposits are communicated to the group 
inventory manager module 17 to ensure that rooms are 

25 assigned only to attendees who have paid their reservation 
deposits. 

Thus, the payment controller module 23 employs 
payment configurator code- for determining when to process 
each type of transaction, requests sets of transactions to 
30 be processed from the attrition enforcer module 29, groups 
transactions to be processed into similar types for batch 
processing, e.g., authorizations, collections, and refunds 
and packages them for delivery to the corresponding 
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payment system. In addition, the payment controller module 
23 has code for distributing status messages for access by 
parties to the settlement process. Finally, the payment 
controller provides result messages to the inventory 
manager which enable rooms for . which reservations have 
been cancelled to be returned to available inventory. 

A major benefit achievable with the central 
reservation and deposit management facility of the 
invention is a substantial reduction in multiple bookings 
and cancelled reservations. Maintaining and enforcement of 
business rules governing the refund and forfeiture of 
deposits discourages cancellations in general. Enforcement 
of an escalating scale of deposit forfeiture amounts 
encourages attendees who must cancel to do so as early as 
possible to enable the rooms to be returned to available 
inventory and rebooked. 

An account for each beneficiary . merchant, e.g., 
hotel operator, is established in an attrition manager 
module 25 (see Fig. 7) in the commmerce processor 
software. Business rules directed to reduction of attendee 
attrition are stored for each combination of beneficiary 
merchant and attendee class. Initial date threshold 
manager code stores a processing fee date for the 
commencement of deposit forfeiture, and threshold dollar 
manager code stores forfeiture dollar amounts which are to 
be applied as a function of date of cancellation. There is 
no forfeiture on cancellations made' prior to the 
processing fee date. Forfeiture charges begin to be 
applied and increase with time from the processing fee 
date until the cancellation close date. There is a one 
hundred percent forfeiture of deposits on cancellations 
made after the cancellation close date. 
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Unit count limit manager code provides a 
predetermined limit on the number of rooms that can be 
reserved by a deposit to a single credit card for 
attendees of each class. VTPs 13 may thereby be allowed 
to reserve more rooms on a credit card than may general 
attendees 11.. 

The unit count limit manager code compares the number 
of rooms sought to be reserved with a . predetermined limit 
on the number of units that can be charged to a single 
credit card for the respective class of attendee, 
irrespective of the amount of the charge. If the result of 
the comparison indicates that the number of rooms sought 
to be reserved on a credit card is less than or equal to 
the predetermined limit assigned to the respective class 
of attendee, the attendees credit card is charged with 
the deposit amount as will hereinafter be explained. 

Thus, the attrition manager module 25 receives 
secured user input, establishes participating beneficiary 
merchant (e.g. hotel operator) accounts, establishes an 
inventory unit count limit per credit card for each class 
of attendee, establishes initial threshold processing fee 
dates, establishes all threshold processing dollar 
amounts, establishes record writing dates for all. other 
steps, and establishes charge amounts for credit card 
transactions. 

An attrition adjuster module 27 (see Fig. 8) contains 
code for determining the times at which cancellation 
penalties are applied in steps occurring from the 
processing fee date until the cancellation close date, the 
amount applied at each step having been established in the 
threshold dollar manager code of the attrition manager 
module 25 . 
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Attrition rules are applied by class of attendee. 
Thus VIPs 13. may be given more favorable treatment on 
cancellation than the treatment given to general attendees 
11. The attrition adjuster code also provides for 
adjusting the attrition step by class of attendee. For 
example, the deposit of a general attendee 11 may be 
penalized more in more frequently occurring steps than the 
deposit of a VIP 13. 

Thus, the attrition adjuster records an attrition 
rule for each attendee class, records multiple attrition 
rule steps for each attendee class, records attrition step 
threshold dates for each attendee class, and records an 
attrition step dollar cost for each attendee class. 

An attrition enforcer module 29 (see Fig. 9) has a 
clock input for continuously receiving time signals from a 
time agent. Threshold listener/ trigger code determines 
when a time has been reached at which refunds for 
prospective cancellations are to be penalized and triggers 
a reduction in the portion of the deposit which may 
thereafter be refunded in response to a cancellation. The 
threshold listener/ trigger code signals action broker code 
to direct that a signal be sent to a payment controller 
module 23 via action actor code. The action/actor code 
updates the threshold listener/ trigger code in preparation 
for the next penalty event. 

Thus, the attrition enforcer identifies a financial 
charge (transaction) for each time thxeshold crossed by 
each attendee as a function of the attendee's class, 
identifies a progress charge amount inversely related to 
proximity to the event start date, and computes a 
diminishing refund for . each prospective cancelled 
reservation consistent with the rule for each class of 
attendee as established by the attrition adjuster. 
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It is to be appreciated that the foregoing is a de- 
scription of a preferred embodiment of the. invention to 
which variations and modifications may be made without de- 
parting from the spirit and scope of the invention. 
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What is claimed is: 

1. A method of reserving rooms for visitors seeking 
hotel accommodations comprising 

storing, in a computer memory, data describing a 
5 plurality of rooms, said data comprising a quality 
classification for each room indicative of a class of 
visitors to whom reservations of said room are to be 
limited, and an inventory code for each of a plurality of 
dates indicative of whether or not said room is available 

10 for occupancy on each of said dates, 

for each visitor storing in said computer memory data 
describing a reservation request made by said visitor, the 
data describing said reservation request comprising a 
visitor class code assigned to said visitor, data 

15 indicating the stay dates for which at least one room is 
sought to be reserved by said visitor, and data 
identifying a financial institution and account therein 
from which collection of a deposit to secure said 
visitor's reservation may be made, 

20 for each visitor, making a comparison of said visitor 

class code with the quality classification for each room 
having an inventory code indicating that said room is 
available for each of the dates for which said reservation 
is sought, and in response to said comparison signaling 

25 the availability, on each of said stay dates, of a room 
having a classification corresponding to said visitor 
class code, changing said inventory code for said room to 
indicate that it is no longer available, said room being 
reserved to said visitor, 

3 0 for each visitor whose reservation has not been 

cancelled by a processing fee date, generating a 
collection request for collecting said visitor's deposit 
payment from said financial institution, and 
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for each visitor whose reservation has not been 
cancelled by a reservation closing date, initiating a 
transfer of funds to said hotel on a funds transfer date, 
said funds being equal in amount to a portion • of said 
5 deposit.. 

2. A method according to claim 1 further wherein 
said closing date is later than said processing fee date. 

3. A method according to claim 2 wherein said funds 
transfer date is later than said closing date. 

10 4. A method according to claim 1 further 

comprising, for each visitor, charging a reservation fee 
comprising a processing fee, the amount of said portion of 
said transferred funds being less than or equal to the 
amount of said deposit reduced by said reservation fee. 
15 . 5 - A method according to claim 4 further 

comprising, for each visitor, charging a deposit fee, the 
amount of said reservation fee being equal to the sum of 
said deposit fee and said processing fee. 

6. A method according to claim 1 further comprising 
20 for each visitor whose reservation has been cancelled 

on or before the fourth date corresponding to said 
visitor, initiating a refund of funds to said visitor, 
said funds being equal in amount to the deposit collected 
from the account of said visitor. 
25 7. A method according to claim 1 further comprising 

for each visitor whose reservation has been cancelled 
on or after the processing fee date and before a 
cancellation date intermediate said processing fee date 
and said fund transfer date, 

computing a cancellation charge amount as a function 
of the date of cancellation of said reservation, and 
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computing the difference between the amount of the 
deposit collected from the account of said visitor and the 
amount of said cancellation charge , and 

if the amount of said cancellation charge is less 
5 than the amount of the deposit collected from the account 
of said visitor, initiating a refund of funds to said 
visitor. 

8 . A method according to claim 7 wherein said 
cancellation charge amount is equal to the sum of a 

10 reservation fee amount and a cancellation penalty amount. 

9. A method according to claim 8 wherein in 
accordance with said function said cancellation penalty 
amount increases as the date of cancellation approaches 
said fifth date. 

15 10. A method according to claim 8 wherein said 

''reservation fee comprises a processing fee charged on or 
after said fourth date. 

11- A method according to claim 8 wherein said 
reservation fee comprises a deposit fee charged on or 
20 after said second date. 

12. A method according to claim 7 further comprising, 
for each visitor whose reservation has been cancelled on 
or after said corresponding sixth date one of a range of 
fifth dates, equal to or later than said fourth date 

25 corresponding to said visitor, initiating a transfer of 
funds to said hotel, said funds being equal in amount to a 
portion of said deposit. 

13 . A method of processing reservation deposits of 
visitors seeking hotel accommodations from a beneficiary 

3 0 merchant in connection with a future event comprising 

maintaining a database with records of reservation 
requests and respective deposit payment offers, 
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comparing the present time with a predetermined time 
for processing said reservation deposits and, if the 
present time is equal to or greater than said 
predetermined processing time, for each record of a 
reservation requested by a visitor, initiating a 
collection request for transferring funds from a financial 
institution in which an account has been opened for the 
benefit of said visitor for payment of said deposit. 

14. A method of processing reservation deposits in 
accordance with claim 13 , further comprising, for each 
record of request for cancellation of a reservation by a 
visitor, comparing the time of said request with said 
processing time, determining from said comparison whether 
a refund is due in response to said cancellation, and 

if a refund is determined to be due, computing the 
amount of said refund as a function of said cancellation 
request time and said processing time, and 

initiating a refund of said amount to said visitor. 

15. A method of processing reservation deposits in 
accordance with claim 14 wherein said computation includes 
subtracting from said deposit a deposit fee irrespective 
of whether said cancellation request time is earlier or 
later than said processing time. 

16. A method of processing reservation deposits in 
accordance with claim 14 wherein said computation includes 
subtracting from said deposit a processing fee, said 
processing fee being a function of the elapsed time 
between said processing time and said cancellation request 
time. 

17. A method of processing reservation deposits in 
accordance with claim 16 wherein each of said visitors is 
assigned to a class of visitors and said processing fee is 
also a function of the class assigned to said visitor. 
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18. A method of processing reservation deposits in 
accordance with claim 16 wherein said processing fee 
increases as said elapsed time increases. 

19. A method of processing reservation deposits in 
accordance with claim 13 , further comprising, for each 
record of request for cancellation of a reservation by a 
visitor, comparing the time of said request with a close 
time subsequent to said processing time, and if said 
cancellation request time is later than said closing time 
determining that no refund is due in response to said 
cancellation request. 

20. A method of processing reservation deposits in 
accordance with claim 13/ further comprising, 

comparing said present time with a predetermined 
funds transfer date later than said close time, and 

if said present time is later than said close time, 
initiating a fund transfer request for transferring funds 
to a financial institution in which an account has been 
opened for the benefit of said beneficiary merchant. 
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